今天终于找到了根本原因：

关于疑似跑得太快导致某高性能 KV 数据库无法及时 reclaim 需要释放的内存，于是暂时只能每两天删掉整个集群再重新加载数据来“回收内存”这件事……

这是真的。跟 ddos 没有区别。哎。

苦了做存档的，开waf的网站越来越多了。公地悲剧。

https://github.com/saveweb/wikiteam3/pull/64

AI 有没有提高生产力我不知道。
我只知道现在在 review 新贡献者的 PR 前，一定要愁一眼发送方的 github activities，看下是不是真人，以防被 AI 自主提交的无厘头 PR 浪费时间。

原来我已经看了这么久的网文了啊。自从看正版以来（
yzq啊yzq，这1k小时干什么不好，浪费到网文上！

可小说真是太好看了，家人们。

今年有网易新闻年终总结吗？

https://http1mustdie.com #今天看了啥
tldr:
- http1 实现各异，难以区分消息的边界，易请求走私。
- proxy 与后端间应当使用 h2。
- 客户端与 proxy 间使用 h1 仍是安全的。

下班

有幸在生产中遇到了生日问题，最终导致数TB数据丢失。故事是这样的。

每个客户端会产生：

{hostname}_{年月日时分秒}_{纳秒的前三位}_{五位递增循环计数}.zst.open

这样的文件，每写满10多GB后重命名去掉 .open 后缀然后上传 S3。
如果客户端爆炸了，会有一个收尸的 rclone 进程把全部的 .open 也上传到 S3。

总之就这样跑了两个星期，产生了 50 多万个 .zst 与 .zst.open 文件，其中有 12 万是爆炸了的 zst.open 文件。（爆炸比例有点高，但是问题不大，主要是 graceful shutdown 坏掉了，于是每次触发新的 k8s 部署都会让所有客户端爆炸。灵）

于是今天要做的事情就是跑一下后处理，把 S3 里的这些 .open 文件，truncate 掉文件尾部的不完整垃圾数据后回传 S3。流程是：
1. 从 S3 下载 .zst.open
2. 本地 truncate .zst.open 并重命名为 .zst
3. 上传 .zst 到 S3
4. 删除 S3 中的 .zst.open

---

理论上，只要每个客户端的 hostname 是唯一的，就永远不会出现同名的 .zst 与 .zst.open。
只有一个例外：我的后处理程序完成了第3步但还未完成第4步时。

我考虑到了这点，于是加了个在步骤1下载 .zst.open 之前先检查一下 S3 里是否存在同名的 .zst 的机制。如果存在，说明上次运行后处理的时候卡在了步骤4，那就直接跳到步骤4重新执行。（幂等）

---

写完后处理的脚本，我丢到服务器上一跑。眨眼间刷了几百上千行 deleting .zst.open 的日志。我愣了十秒，“不对劲啊，我第一次跑，怎么会有同名文件呢”，赶紧 ctrl-c （已经晚了，删得只剩下十几个 .zst.open）。

---

一分钟后突然意识到我这是遇到了生日问题。因为每个客户端的 hostname 其实并不是唯一的！

之前可能是为了提高网络性能，同事把容器的网络从 bridge 改成了 host，导致 hostname 从原本随机生成的变成了跟随宿主机。

这次运行又比较猛，平均每个宿主机上起了三四个容器（客户端），每个客户端会在启动时几乎同时创建 64 个 .open 文件用于写入。

再加上我们取的纳秒的前三个数字而不是后三位数字，扩大了同一宿主机上不同客户端在一秒内启动时的碰撞概率。

最终导致不同客户端有极小概率创建出同名的文件而撞车。又因为跑了两个星期创建出了50万文件，极小概率撞车变成了必定有几百上千个撞车的生日问题。

---

还得幸亏我们的客户端的 graceful shutdown 很灵车，致使爆炸的 .open 文件很多，暴露出了这个问题。要是我们的 graceful shutdown 做得更完善一点，最终的结果会是 S3 没有这么多 .open 文件，撞车文件都会静默覆盖原本的同名文件，可能我们得要很久很久以后才能意识到这个问题。

https://blog.cosine.ren/post/git-worktrunk-guide

我也觉得 worktree 啰嗦了，试了下 worktrunk (https://worktrunk.dev/)，确实好用。